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(54) Computer systenrt with multiple operating system operation 

(57) A computer system is provided with a scheme 
to making the input and output device provided in a 
computer in common for a plurality of operating system, 
in a multiple operating system control unit operating a 
plurality of mutually distinct operating systems on one 
computer system. The computer system includes a plu- 
rality of operating systems, and OS switching unit for 
switching a plurality of operating systems. The OS 
switching means makes reference to a preferential inter- 
rupt table on the basis of an inten-upt factor for switching 
to corresponding operating system and calls interrupt 
processing means incorporated in the operating sys- 
tem. 
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Description 

[0001] The present invention is directed to a data 
inputting and outputting method to a peripheral devices 
in a computer system operating with a plurality of oper- 5 
ating systems on a single processor, and is related to a 
control method for using the same peripheral device In 
common for a plurality of operating systems In common. 
Description of the Related Art 

[0002] In normal computer, one operating system is io 
operated. The operating system manages resources of 
the computer, such as a processor, a memory and a 
secondary storage device and performs resource 
scheduling so as to operate the computer efficiently 
Here, there are various kinds of operating systems. One is 
is superior in batch process, another is superior in GUI 
such as an office work, the other is superior in a real 
time process. In order to bring out feature of a plurality 
of operating systems, there Is a needs to execute a plu- 
rality of operating systems simultaneously on the single 20 
computer. For example, in case of a large size compu- 
ter, it has been demanded to operate an operating sys- 
tem executing an on-line process associated with an 
actual business or an operating system for develop- 
ment. Also, it is demanded to operate an operating sys- 25 
tem provided with GUI and an operating system 
superior in real time characteristics. 
[0003] As a mechanism for operating a plurality of 
operating systems on one computer, there is a virtual 
computer system (OS Series Vol, 1 1 , VM, Tomoo OKA- 30 
ZAKI, Kyoritsu Shuppan K.K.) which has been realized 
in a large size computer, In the virtual computer system. 
A virtual computer control program occupies and man- 
ages all hardware and make it virtual to form the virtual 
computer. A control portion forming the virtual computer 35 
makes a physical memory, an input and output device, 
an external interrupt and so forth virtual. For example, 
• divided physical memory behave as if a physical mem- 
ory starting from zero address for the virtual computer. 
Unit numbers identifying the input and output device are 40 
also made virtual. Furthermore, by dividing a storage 
region of a magnetic disk to realize even making a mag- 
netic disk drive virtual. 

[0004] On the other hand, as a technology for pro- 
viding Interface for a plurality of operating system In one 45 
computer, there is a micro kernel. In the micro kernel, 
an operating system server for providing operating sys- 
tem function to be shown to the user on micro kernel, is 
established. The user utilizes a resource of the compu- 
ter via the server. By providing servers for each operat- so 
ing system, it becomes possible to provide various 
operating system environments for the user. 
[0005] For example, in case of a vehicle mounting 
navigation system, importance is given for a real time 
characteristics for instantly responding to variation of 55 
external environment and a reliability as to not to stop 
the system. Therefore, a real time operating system 
(real time OS) having a compact module construction 



with high interruption response is frequently used. How- 
ever, the real time OS cannot be said to have superior 
interface with a person, while it gives importance for real 
time characteristics and reliability. On the other hand, 
an office work operating system (general purpose OS) 
to be typically used in typical personal computer (PC) is 
provided an environment for directly operating a display, 
such as GUI to provide superior human interface. 
Therefore, a demand to use a user Interface of the gen- 
eral purpose OS even in the field where the real time 
OS has been used conventionally, is growing. However, 
since the general purpose OS takes interactive process 
with the person, it gives greater importance for a 
throughput of the process rather than response charac- 
teristics to inten'upt process and thus is possible to exe- 
cute a process with maintaining interrupt inhibiting 
condition for a relatively long period. On the other hand, 
in comparison with the real time OS having compact 
construction, it cannot be said comparable in reliability. 
[0006] However, similarly to a system for operating 
a plurality of virtual computers (operating systems) in 
parallel on the large size computer, if the general pur- 
pose OS and the real time OS can be operated in the 
same computer system in a build-in system to switch 
the operating system as required, it may be possible to 
achieve both of superior used interface and real time 
characteristics and reliability. Considering improvement 
of performance of the microprocessor, operating a plu- 
rality of operating systems in one computer systehi has 
not been a technology permitted only the large size 
computer. 

[0007] While it is required to be adapted for multiple 
users in the large computer, whereas a built-in equip- 
ments may be required to be at least adapted to a single 
user in the build-in equipments. Therefore, when the 
real time OS and the general purpose OS are operated 
in the single system, a simplest operating system 
switching method in consideration of importance of 
respective operating systems, if a process to be exe- 
cuted in the real time OS is present, to operate the real 
time OS preferentially and to operate the general pur- 
pose OS when the task to be executed on the real time 
OS is not present, is applicable. In such switching 
method the operating systems, a method of switching of 
the operating system by discriminating the interrupt 
number generated, by statically determining the operat- 
ing system receiving the interrupt demand per input and 
output devices in inputting and outputting with the 
peripheral device. For example, when the foregoing 
method is applied to the vehicle mounted navigation 
system, the operating system is switched so that an 
interrupt handler of the real time OS is actuated for the 
interrupt from the sensor necessary for determining the 
position and an interrupt handler of the general purpose 
OS is actuated for interrupt from a display controller. 
However, since the reliability of the general purpose OS 
is not necessarily high, in the shown application, proc- 
ess of the general purpose OS is stopped, the user 
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interface becomes impossible to use to lower reliability 
of the overall vehicle mounted navigation system. In 
order to solve the foregoing problem, the process may 
be divided to assign the process which is desired to 
never be interrupted to the real time OS side and to 
assign the process permitting interruption to the general 
purpose OS side. However, if the input and output proc- 
ess for the user interface is process on the side of the 
real time OS, introduction of the general purpose OS 
superior in user interface becomes meaningless. There- 
fore, it becomes essential to pemilt use of the input and 
output device from a plurality of operating systems, 
namely from both of the general purpose OS and the 
real time OS. Therefore, a problem Is encountered in 
that it is insufficient to statically determine the operating 
system to execute the input and output process from the 
inten'upt number as set forth above, and cannot be 
applicable for practical use. 

[0008] An object of the present invention to provide 
a scheme to making the input and output device pro- 
vided in a computer in common for a plurality of operat- 
ing system, in a multiple operating system control unit 
operating a plurality of mutually distinct operating sys- 
tems on one computer system. 
[0009] In order to accomplish the above*mentioned 
object, According to the first invention, a computer sys- 
tem including a plurality of operating systems, and an 
OS switching means for switching a plurality of operat- 
ing systems, characterized in that said OS switching 
means makes reference to a preferential interrupt table 
on the basis of an inten-upt factor for switching to corre- 
sponding operating system and calls inten'upt process- 
ing means incorporated in said operating system for 
making the input and output device provided in the com- 
puter system in common for a plurality of operating sys- 
tems.. 

[0010] According to the second invention, a compu- 
ter system having a plurality of operating systems and 
OS switching means for switching a plurality of operat- 
ing systems, characterized by including peripheral 
device to be common for a plurality of operating sys- 
tems, data inputting and outputting server for inputting 
and outputting data with the peripheral device to be 
used in common, providing in one of the operating sys- 
tems, data inputting and outputting client for inputting 
and outputting data with the operating system other 
than said one operating system, requesting inputting 
and outputting data to said data inputting and outputting 
server and executing inputting and outputting of data by 
receiving a result of data inputting and outputting with 
the peripheral server in the data inputting and outputting 
server. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] The present invention will be understood 
more fully from the detailed description given hereinaf- 
ter and from the accompanying drawings of the pre- 



ferred embodiment of the present invention, which, 
however, should not be taken to be limitative to the 
invention, but are for explanation and understanding 
only. 

5 [0012] In the drawings: 

FIG. 1 is an illustration showing a system construc- 
tion in the first embodiment of the present invention; 
FIG. 2 is an illustration showing a hardware con- 
10 struction of a computer system; 

FIG. 3 is an illustration showing a status register in 
the case where an interrupt level mask function is 
provided; 

FIG. 4 is an illustration showing a status register in 
15 the case where an individual interrupt mask func- 
tion is provided. 

FIG. 5 is a first illustration showing a detail of an 

interrupt processing program; 

FIG. 6 is an illustration showing a construction of 
20 the interrupt address table; 

FIG. 7 is an illustration showing a construction of a 

preferential inten-upt table; 

FIG. 8 is an illustration showing a process flow of an 

OS context switch module; 
25 FIG. 9 is a first illustration showing a process flow of 

a common inten-upt handler; 

FIG. 1 0 is a first illustration showing a process flow 

of an interupt handler; 

FIG. 11 is an illustration showing a construction of 
30 an input and output panel of a vehicle mounted nav- 
igation system; 

FIG. 12 is an illustration showing a construction of a 
switch table; 

FIG. 13 is a second illustration showing the process 
35 flow of the common interrupt handler; 

FIG. 14 is a second illustration showing the system 
construction in the second embodiment of the 
present invention; 

FIG. 15 is a third illustration showing the process 
40 flow of the common interrupt handler; 

FIG. 16 is a second Illustration showing the process 

flow of the interrupt handler; 

FIG. 17 is a third illustration showing the process 

flow of the intemjpt handler; 
45 FIG. 18 is a first illustration showing a detail of an 

input and output processing program; 

FIG. 19 is a second illustration showing a detail of 

an input and output processing program; 

FIG. 20 is an illustration showing a flow of re-writing 
50 a preferential Interrupt table; and 

FIG. 21 is an illustration showing a construction of a 

system in which the present invention is applied to 

a graphic display device. 

55 [0013] The present invention will be discussed 
hereinafter in detail in tenms of the prefen-ed embodi- 
ment of the present invention with reference to the 
accompanying drawings. In the following description, 
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numerous specific details are set forth in order to pro- 
vide a thorough understanding of the present invention. 
It will be obvious, however, to those sl<illed in the art that 
the present invention may be practiced without these 
specific details. In other instance, well-l<nown structure 5 
are not shown in detail in order to avoid unnecessary 
obscurity of the present invention. 
[001 4] Embodiments of a computer system accord- 
ing to the present Invention will be discussed with refer- 
ence to the drawings. 10 
[0015] An overall construction in the first embodi- 
ment of the computer system according to present 
invention is illustrated in Fig. 1 . Normally, a computer 
system is constructed with a processor 1 00, a memory 
101, an input and output control device 102, a display is 
1 04, a switch 1 05, a sensor 1 06 and so forth. The proc- 
essor 100, the memory 101 and the input and output 
control device 102 are connected by a processor bus 
103. The processor 100 is a microprocessor for operat- 
ing a plurality of operating systems. The memory 101 20 
stores operating systems 116 and 117, tasl< programs 
110 to 115 operated on respective operating systems, 
input and output driver programs 120 and 121 for 
respective operating systems, interrupt handler pro- 
grams 122 and 123, and Inter-OS control function pro- 25 
gram 124. These programs are read from the memory 
101 and executed by the processor 100. 
[0016] The input and output control device 102 is 
connected with a display 104 as an image display 
device, a switch 105 for receiving a command from a 30 
user, a sensor 106 for detecting variation of peripheral 
environment and so forth. On the other hand, upon real- 
izing a factory/plant controlling or built-in computer sys- 
tem, a networl< 109 may be connected to the input and 
output control device 1 02. To the network 1 09, an input 35 
and output equipment, such as a communication equip- 
ment and so forth, is connected. It should be noted that 
among input and output devices 104 to 106 connected 
to the input and output control device 1 02, any one or all 
of the input and output devices may be omitted in some 40 
system configuration. Furthermore, wide variety of input 
and output devices may be connected for notifying com- 
pletion of input and output operation and so forth. In Fig. 
1 , while the interrupt signal line 1 08 and the processor 
bus 103 are illustrated as separate devices for the pur- 45 
pose of illustration, the interrupt signal line is a part of 
the processor bus 1 03, in practice. Within the processor 
1 00, a timer device 1 07 is provided to cause an internal 
interrupt per a given period. An intemipt caused by the 
timer device 1 07 is used for time measurement of the so 
operating system or the lil<e. 

[0017] The processor 100 is provided with a func- 
tion for masking an external interrupt command input 
through the interrupt signal line 108 and an internal 
Interrupt command from the timer device 107 and so ss 
forth. The masking of interrupt is a function for delaying 
a particular Interrupt until masking of interrupt is 
released by a program. Typically, as the inten-upt mask- 



ing functions, the following three kinds are present. 

(1) All Interrupt Mask: All of interrupts are masked. 

(2) Individual Inten-upt Mask: Each individual inter- 
rupt is masked. 

(3) Interrupt Level Mask: Level is set for each inter- 
rupt for masking interrupt lower than or equal to a 
designated level. 

[0018] Depending upon kind of the processor 100, 
interrupt masking of a combination of the foregoing (1) 
and (2) or a combination of (1 ) and (3) may be provided, 
frequently. When the processor having the latter combi- 
nation is employed, the interrupt level is assigned 
depending upon importance and minimum response 
period of the corresponding input and output device. For 
example, an intenrupt from a network requiring a short 
response period is set at higher level than that of the 
interrupt from the switch 105, the storage device 106 
and so forth. 

[0019] In the shown embodiment, discussion will be 
given for the case where two operating systems 1 1 6 
and 1 1 7 are present in the computer system. The oper- 
ating systems 116 and 117 execute tasks 110 to 115 
using memory assigned for each operating system and 
a resource of the processor. While Fig, 1 shows an 
example where number of operating systems is two and 
total number of the tasks is six, it is possible to load the 
operating systems or tasks in greater or smaller number 
than that illustrated. While the shown embodiment does 
not consider dynamic variation of number of the operat- 
ing systems, it is possible that each operating system 
dynamically generate and delete the takes. Further- 
more, in the shown embodiment, it is assumed that the 
operating system 1 1 6 is the general purpose OS which 
is adapted for word processing, data processing and so 
on and the operating system 117 is the real time OS 
which requires real time response, such as computer 
games, navigation system and so forth. However, the 
technology descried In the present invention is applica- 
ble for any kind of the operating systems. The tasks 1 1 0 
to 1 1 2 are tasks to be executed by the general purpose 
OS, and the tasks 1 13 to 1 15 are real time tasks to be 
executed by the real time OS. Also, the following discus- 
sion will be given with an assumption that preferential 
order of interrupt of the real time OS is higher than that 
of the general purpose OS in order to guarantee a 
response period in the real time OS. In the assumption, 
when any one of the tasks of the real time OS is in exe- 
cution, the real time OS 116 uses the resource of the 
processor. When all of the tasks are in idling condition 
or waiting condition, the context is switched to the gen- 
eral purpose OS so that the general purpose OS uses 
the resource of the processor. 
[0020] The inter-OS control function 1 24 is provided 
for operating the general purpose OS 1 16 and the real 
time OS 1 17 in cooperation with each other. The inter- 
OS control function 124 includes a common memory 
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125 accessible from both of the general purpose OS 
and the real time OS, an inter-OS communication func- 
tion 1 26 for performing transfer of message between the 
general purpose OS and the real time OS, an OS con- 
text switching function 127 for switching executing envi- 
ronment of the general purpose OS and the real time 
OS, a common Interrupt handler 12B for distributing the 
generated interrupt commands to respective operating 
systems, and a preference management table 129 stor- 
ing the operating systems corresponding to the interrupt 
demands or interrupt start addresses. 
[0021] The common memory 125 intends the real- 
ize high speed data exchange between the operating 
systems and can read and write out and in by both of 
the general purpose OS and the real time OS. Here, In 
order to avoid conflict of data, It is desirable to exclu- 
sively access the common memory using a semaphore 
function. The inter-OS communication function 126 pre- 
pares a message queue corresponding to respective 
operating system for transferring the message between 
respective operating systems. The common interrupt 
handler 1 28 initially call upon generation of the interrupt 
demand to detennine the operating system per interrupt 
number stored in the preferential inten^upt table 129 to 
call the corresponding interrupt handler 122 and 123. 
The OS context switching function 127 switches context 
as judged that switching of the operating system is nec- 
essary in response to the interrupt demand or calling of 
inter-OS control function. The interrupt management 
table 129 stores the operating system information, in 
which the inten-upt handler called per inten-upt number 
belongs, and start address information of the interrupt 
handler per operating system. In the conventional 
method, the interrupt management table 129 statically 
determines upon starting up of the system. Therefore, 
the content could not be re-written during system oper- 
ation. In the shown system, by providing re-writing 
means for re-wrlting the inten-upt management table 
129 even during system operation, common use of one 
input and output device with a plurality of operating sys- 
tems is enabled. 

[0022] The operating systems 1 1 6 and 1 1 7 has the 
input and output drivers 120 and 121 for processing 
data input and output with the input and output device 
and the interrupt handlers 122 and 123 for receiving 
Interrupt demand from the input and output devices. 
The interrupt handlers 122 and 123 are called from the 
common interrupt handler 1 28. One of the Interrupt han- 
dlers 122 and 123 called by the common inten-upt han- 
dler 128 executes interrupt processing program defined 
by the user. The input and output drivers 120 and 121 
provide interfaces for controlling the input and output 
devices and provide functions for inputting and output- 
ting data by reading and writing data from and in the 
Input and output device and controlling the input and 
output device. Re-schedulers 1 18 and 119 initiate oper- 
ation in the case where task has to be switched associ- 
ating with generation, deletion, stopping, and restoring 



of task, external inten-upt or internal interrupt. The re- 
scheduler stores execution environment (program coun- 
ter, status register, general purpose register and so 
forth) of the task executed immediately before in a task 
5 management table, determines to be newly executed, 
takes out the execution environment from the task man- 
agement table to set in respective registers to execute 
the selected task. 

[0023] Fig. 2 shows an example of internal con- 

70 struction of the processor premised in the present 
invention. A cache memory 130 is a buffer storage 
device for temporarily storing data or instruction on the 
memory 101. CPU 131 is an arithmetic circuit and 
sequentially executes instructions present on the mem- 

15 ory 101 or the cache memory 130. Upon execution of 
the instruction, a general purpose register 132 tempo- 
rarily storing the result of arithmetic operation, a pro- 
gram counter 133 for storing an execution instruction 
address and a status register 1 34 for storing execution 

20 status. The cache memory 130. CPU 131, the general 
purpose register 132, the program counter 133, the sta- 
tus register 134 are connected with each other by a data 
bus 135 for transferring data and an address bus 136 
perfomning address designation. 

25 [0024] The interrupt signal line 108 and the timer 
device 107 are connected to an interrupt controller 137. 
The interrupt controller 137 has a function for generat- 
ing interrupt state signal 138 with respect to CPU 130. 
The inten-upt state signal 138 is a signal line indicating 

30 what kind of interrupt is currently occurred on the proc- 
essor 100. Nonnally, the status register 134 has infor- 
mation relating to current inten-upt mask to determine 
whether inten-upt designated by the inten-upt status sig- 
nal 138 is accepted or not. Upon accepting interrupt, the 

35 interrupt controller 137 re-wrltes the program counter 
1 33, the status register 1 34 and so forth to execute cor- 
responding interrupt processing program. 
[0025] An example of structure of the status register 
134 is shown in Rg. 3. Here, an example of the case 

40 where all interrupts masking function and inten-upt level 
masking function are provided in the processor 100. In 
the example of Fig. 3, the status register 134 has an 
interrupt block bit 140 and an interrupt mask level field 
141. When the interrupt block bit 140 Is ON, all infer- 
os rupts to the processor 100 is masked. The interrupt 
mask level field 141 shows the current interrupt mask 
level value, and interrupt level lower than or equal to this 
level is not accepted. In case of the example shown In 
Fig. 3. the interrupt mask level field 141 has a length of 

50 four bit length. Therefore, sixteen kinds in total of the 
mask levels can be designated (normally, the interrupt 
level 0 represent "interrupt does not occur", and thus fif- 
teen kinds In practice). By varying the bit number of the 
interrupt mask level field 141, kind of the inten-upt level 

55 to accept can be increased and decreased. 

[0026] Fig. 4 shows the status register 134 for the 
case where the processor 100 is provided with all inter- 
rupt masking function and individual interrupt masking 
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function. In this example, the status register 134 is con- 
structed with two registers (an execution status register 
142 and in interrupt masl<ing register 143). Similarly to 
Fig. 3, the inten^upt block bit 140 in the execution status 
register 142 is provided. Inten-upt masl< bits 1 44 to 1 47 5 
in the inten-upt maslcing register 143 correspond to 
inten-upt separately. When any one of the interrupt 
mask bits is turned ON, reception of the corresponding 
interrupt is prohibited. The example of status register 
shown in Fig. 3 is special example of the status register 70 
1 34 of Fig. 4. For example, a state where only intenrupt 
mask bit 144 is ON, is referred to as level 1 . When two 
of the inten-upt mask bits 1 44 and 1 45 are ON, the state 
is referred to as level 2. When three of the intenrupt 
mask bits 140 to 146 are ON, the state is refen-ed to as 75 
level 3, ... for establishing correspondence. Therefore, in 
the following disclosure, the status register 134 will be 
discussed to have the construction shown in Fig. 4. 
[0027] In general processor, upon reception of 
inten-upt, the interrupt block bit 140 is automatically re- 20 
written to ON by hardware. As required, the intenrupt 
processing program re-writes the inten-upt block bit 140 
to OFF to enable accepting interrupt. On the other hand, 
it is also possible to temporarily re-write the contents of 
the inten-upt block bit 140 and the interrupt mask regis- 25 
ter 143 by the operating system and the task to place 
the system to wait for reception of a particular interrupt. 
The interrupt masking function is used for realizing 
exclusive control and avoiding occun-ence of the same 
inten-upt during execution of interrupt process. 30 
[0028] Rg. 5 shows detail of the interrupt handlers 
122 and 123, the common interrupt handler 128, the OS 
context switching function 127 and the inten-upt man- 
agement table 129. 

[0029] The interrupt handler 122 and 123 have 35 
inten-upt stacks 151 and 153 respectively as regions for 
storing register and so forth upon occurrence of inter- 
rupt and storing a temporary parameter. The inten-upt 
stacks 151 and 153 are provided for storing register 
value immediately before occurrence of interrupt and 40 
returning the register value to the original value after 
completion of the interrupt process, upon occurrence of 
inten-upt. Some kind of processor 100 to be used, a 
function to automatically switch the register upon occur- 
rence of interrupt and to return to the register before 45 
switching after the interrupt process. However, in con- 
sideration of the system permitting multiple interrupts, 
stack becomes necessary even in using such hardware 
(when interrupt having higher preference occurs during 
process of Interrupt, the newly occurred interrupt proc- so 
ess is executed preferentially, and then has to return to 
the original inten-upt process). The interrupt handlers 
122 and 123 has inten-upt stack pointers 150 and 152 
as pointers showing what region is used In the inten-upt 
stacks 151 and 153. The Interrupt handlers 122 and 123 ss 
store execution environment (register and so forth) 
using the inten-upt stack pointer to execute necessary 
interrupt process. After completion of the inten-upt proc- 



ess, the execution environment before occurrence of 
interrupt Is resumed to continue originally executed pro- 
gram. 

[0030] The common interrupt handler 128 has a 
function for distributing occurred interrupt to the inter- 
rupt handlers 122 and 123. Therefore, the common 
interrupt handler 128 has an executing OS storage 
parameter 154 as a region for storing which of the gen- 
eral purpose OS 116 and the real time OS 117 is the 
operating system currently executed. For example, 
assuming that the general purpose OS is in execution at 
the time of Fig. 5, "general purpose OS" is stored in the 
executing OS storage parameter 154, in this case. Of 
course, since it is quite inefficient to store the character 
string "general purpose OS" in the executing OS stor- 
age parameter 1 54, it may be stored in a form of integer, 
such that 0 is stored if the general purpose OS is in exe- 
cution and 1 is stored if the real time OS is in execution. 
[0031] The interrupt management table 129 has a 
preferential inten-upt table 156 indicating which interrupt 
handler of one of the operating system is to be actuated 
and an interrupt address table 155 indicating a start 
address of the interrupt handlers included in respective 
operating systems. The preferential interrupt table 156 
is constructed with a corespondence table indicating 
which of the operating systems processes the Individual 
interrupt as shown in Fig. 7, for example to request 
process to the interrupt handler of the operating system, 
for which the flag 1 is stored. Furthemnore, for interrupt 
from the input and output device common for a plurality 
of operating systems, flag is set to 1, and not common 
interrupt, flag 0 is stored. In the shown embodiment, 
assuming that sixteen kinds of inten-upt factors are 
present, the interrupt correspondence table 156 is 
formed with sixteen entries (IRQ#0 to IRQ#15). In this 
disclosure, it is premised a method for storing a flag in a 
preferential driver table 1 60, it may be realized by any 
method by storing some Identifiable information. The 
interrupt address table 155 is a table holding start 
address of the Inten'upt handler included in each oper- 
ating system as shown in Fig. 6, for example. 
[0032] In the present invention, in order to achieve 
the object to use one input and output equipment for a 
plurality of operating systems in common, a mechanism 
for dynamically varying the operating system to be actu- 
ated from the interrupt demand received by the com- 
mon inten-upt handler 128. The content of the 
preferential interrupt table 156 is updated depending 
upon the user operation and use condition of the input 
and output equipment. The common interrupt handler 
128 operates to call interrupt handler according to the 
content of the preferential interrupt table 156. In further 
detailed discussion, the common interupt handler 128 
make reference to the executing OS storage parameter 
154 to make judgment of the kind of the currently exe- 
cuted operating system. If the kind of the operating sys- 
tem does not match with the operating system to be 
assigned obtained from the preferential inten-upt table 
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1 54, switching of the operating system is requested to 
the OS context switch module 127. Upon completion of 
switching of the operating system or if the operating sys- 
tem matches and thus switching is unnecessary, proc- 
ess is requested to the interrupt handler of the 
corresponding operating system. It should be noted that 
the executing OS storage parameter 154 is made refer- 
ence to even from the OS context switch module 127. 
The internal structure having respective modules In the 
inter-OS control function program, is not limited to that 
occupied by individual modules but can be common in 
respective modules as required. 
[0033] The OS context switch module 127 is actu- 
ated when the operating systems are to be switched as 
a result of calling of the inter-OS control function or 
occurrence of interrupt In order to switch between the 
operating systems, the region for storing the execution 
environment (namely, register value) is provided. In the 
drawing, as the region for storing the execution environ- 
ment of the general purpose OS in the drawing, a stor- 
age context for general purpose OS 157 is prepared, 
and as a region for storing execution environment of the 
real time OS, a storage context 158 for real time OS is 
prepared. The OS context switch module 1 27 stores the 
execution environment in the storage context corre^ 
sponding to the currently executed operating system 
upon switching of the context. Next, the execution envi- 
ronment is read out from another storage context to set 
in the register of the processor 1 00. By this, switching of 
the operating system can be performed. Subsequently, 
discussion will be given for process flow of the OS con- 
text switch module 127, the common inten-upt handlers 
128 and the inten-upt handler 122 among the modules 
shown in Fig. 5. Concerning the interrupt handler 123, 
since it has the same flow as the interrupt handler 122, 
discussion will be omitted. 

[0034] Fig. 8 is a process flow of the OS context 
switch module 127. The OS context switch module 127 
is called only when the operating systems to be exe- 
cuted are to be switched. Checking whether switching is 
necessary or not, is performed before calling. Accord- 
ingly, with reference to the executing OS storage param- 
eter 154, check is performed as to which operating 
systems switching is to be made (process 160). Here, 
upon switching from the general purpose OS 1 1 6 to the 
real time OS 1 17, the value of the register being used is 
temporarily stored in the storage context 157 for the 
general purpose OS (process 161). Then, by resuming 
the execution environment from the storage context 158 
for the real time OS to set in the register (process 1 62), 
the real time OS can be re-executed from the temporar- 
ily stored condition. Upon switching from the real time 
OS to the general purpose OS, conversely, the value of 
the register being used is temporarily stored in the stor- 
age context for the real time OS (process 163). Next, 
the register 157 is resumed from the storage context 
157 for general purpose OS (process 164). In either 
case, finally, the kind of the operating system after 



switching is written in the executing OS storage param- 
eter 154 (process 165). 

[0035] Fig, 9 shows the process flow of the com- 
mon interrupt handler 128. In general, in the computer 

5 system controlled by a single operating system, all of 
interrupts are once processed by a module called as 
interrupt handler, then is distributed to respective pro- 
grams. However, in case of the computer system oper- 
ating a plurality of operating system as discussed in the 

TO shown embodiment, all interrupts are received by the 
common interrupt handler further before to distribute 
the interrupts to the interrupt handlers of the con^e- 
sponding operating systems. Upon distribution of Inter- 
rupts to respective operating systems, upon occurrence 

15 of interrupt, it is possible that the operating system other 
than objective for intenrupt is in execution. In this case, it 
becomes necessary to switch to the operating system 
corresponding to inten*upt The common interrupt han- 
dler also has such function. 

20 [0036] The common handler 128, at first, takes out 
the content of the executing OS storage parameter 154 
to check whether the operating system currently exe- 
cuted is the general purpose OS 1 1 6 or the real time OS 
117 (process 170), upon occurrence of interrupt. Next, 

25 reference is made to the preferential interrupt table 156 
to attain which of the interrupt handler of the operating 
systems is to be actuated by the generated interrupt 
demand (process 1 71). Considering the case where the 
value in the preferential interrupt table 156 shown in Fig. 

30 6 is used, the operating system con'esponding to the 
value can be attained in such a manner that when the 
interrupt IRQ#0 occurs, the real time OS, when the 
interrupt IRQ#1 occurs, the general purpose OS 1 17, ... 
when the interrupt IRQ#15 occurs, the real time OS 

35 117. Next, check is performed whether the obtained 
interrupt objective operating system matches with the 
operating system in execution or not (process 172). If 
the interrupt demand is not for the cunrently executed 
operating system, the operating system has to be 

40 switched once. This switching process is performed by 
requesting switching to the OS context switch module 
127 (process 173). Next, check is perfomned whether 
the interrupt objective operating system is the general 
purpose OS 1 1 6 or the real time OS 1 1 7 (process 1 74). 

45 If the object is the genera! purpose OS 1 1 6, the Interrupt 
handler 122 of the general purpose OS is actuated with 
reference to the inten-upt address table 155 (process 
175). If interrupt is caused in the real time OS 1 17, ref- 
erence is made to the interrupt address 155, similarly, , 

50 the interrupt handler 123 of the real time as is actuated 
(process 176). In general, when switching of task has to 
be performed in the interrupt process, the interrupt han- 
dler 122 and 123 calls the re-schedulers 1 1 8 and 1 1 9 so 
as not to return the control to the common intenrupt han- 

55 dier 1 28. However, when task switching does not occur, 
the process of the interrupt handler is terminated. At this 
time, the interrupt handlers 122 and 123 returns control 
to the common interrupt handler (discussed later in con- 
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nection with Rg. 10), and the common inten-upt handler 
resumes operation from process 177. Process 177 is a 
process for checking whether the operating systems are 
switched upon occurrence of interrupt. When the oper- 
ating system is switched at process 173, the operating 5 
system has to be switched again to return to the original 
execution environment. Therefore, request is made to 
the OS context switch module 127 for execution of the 
switching process (process 178). 

[0037] Rg, 1 0 shows a process flow of the inten-upt 10 
handler of the general purpose OS called from the com- 
mon interrupt handler 128. At first, the register in use is 
temporarily stored in the interrupt stacl< 151 (process 
180) to execute the interrupt process (process 181). 
Here, check is made whether the operating system is in 15 
re-scheduling or not (namely, whether the re-scheduler 
is in execution of the process or not) (process 182). In 
re-scheduling means that the take to be executed next 
is now in selection, and the task is not actually in execu- 
tion/ Accordingly, when the process of the operating 20 
system can be simplified, the re-scheduling in this case 
can be done again from the beginning. Namely, when 
judgment is made that the re-scheduling is current in 
execution, the temporarily stored register of the inter- 
rupt stack is abandoned (process 1 87) to actuate the re- 25 
scheduler 118 from the beginning (process 188). It 
should be noted that there is some cases, In which the 
task in execution is not necessary to be newly selected 
even when interrupt occurs during re-scheduling. In the 
shown system, even in this condition, rescheduling has 30 
to be perfonned from the beginning and thus is not effi- 
cient Therefore, it is possible to employ a method to 
register the process (e.g. task initiation, termination and 
so forth) possibly influence for execution of the re- 
scheduler 118, occurring during re-scheduling in a 35 
queue. In this case, the process registered in queue 
before completion of re-scheduling, is executed aggre- 
gatingly When this system is employed, it becomes 
unnecessary to re-do re-scheduling executed to the 
mid-way at every occurrence of interrupt. However, after 40 
aggregatingiy executing the process stored in the 
queue, check has to be done again whether re-schedul- 
ing Is to be performed or not. It should be noted that, in 
the shown embodiment, discussion will be given with 
the fonner system for simplification. However, when the 45 
latter system is employed, a flag indicative of re-sched- 
uling being in process or not or a process queue may be 
prepared. In system call or so forth provided by the 
operating system, the process influencing for execution 
of the re-scheduler 118 is registered ion queue if re- so 
scheduling is in execution. Furthermore, during process 
flow of re-scheduler 118, a module to aggregatingiy 
executing the processes registered in queue is inserted. 
[0038] When the interrupt handler 1 22 makes judg- 
ment that the re-scheduling is not In execution, the oper- 55 
ating system should be in execution of certain task at 
that timing. Therefore, at first, check is made whether 
task switching is necessary or not (process 183). If 



switching of the task is unnecessary (currently executed 
task is the highest preferential order and is executable), 
the process of the interrupt handler 122 is terminated 
with no change. Therefore, the register value temporar- 
ily stored in the interrupt stack 151 is recovered (proc- 
ess 184) and control is returned to the common 
interrupt handler (process 185). If judgment is made 
that switching of the task is necessary, the value of the 
register temporarily stored in the interrupt stack 161 is 
copied to the task management table (process 1 86), the 
temporarily stored register of the inten-upt stack is aban- 
doned (process 187) and then the re-scheduler 118 is 
actuated (process 188). It should be noted that if the 
process 1 00 is provided with a function to increase and 
decrease the value of the interrupt stack pointer 150 
together with making reference to data on the memory 
101, the processes 186 and 187 can be executed In a 
lump. 

[0039] As set forth above, the method for using the 
input and output device in common for a plurality of 
operating systems by making reference to the preferen- 
tial interrupt table 156 provided in the inter-OS control 
function 124, and actuating the interrupt handler after 
determination of the operating system to be operated. 
However, It is possible to occur the case where the 
operating systems cannot be uniformly determined from 
the interrupt number for some input and output device. 
For example, in an input and output panel of a vehicle 
mounted navigation system shown in Fig, 1 1 , for exam- 
pie, a switch 105 for inputting a command by the user 
and a display 104 for displaying a result are provided. 
The switch 1 05 preferably includes a dedicated switch 
190 for real time OS, which is used by only tasks pro- 
vided in the real time OS 1 1 7, a dedicated switch 1 91 for 
office work and a common switch 192 which can be 
used in common from the tasks provided in both of the 
operating systems. By providing the dedicated switches 
per operating system, frequently used function can be 
fixedly assigned to the switches to attain a feature to 
improve operability. Furthemiore, by assigning the func- 
tion to the fixed switch, function name can be displayed 
on the button to improve identifiability. However, provid- 
ing distinct interrupt number per switch is disadvanta- 
geous in viewpoint of constraint of number of interrupt 
signal lines and simplification of the hardware. On the 
other hand, by assigning the same intenrupt number to 
the switches. It becomes impossible to detenmine which 
interrupt handlers of the operating systems is to be 
actuated upon depression of the switch, in order to 
solve this problem, a switch table 200 is provided in the 
common memory 125 provided in the inter-OS control 
function 124. In the switch table, information of the 
switch to be used by which operating system is stored 
per switch, in Fig. 12, in the switch table, "real time OS", 
"general purpose OS" and "common" are stored. Of 
course, storing the character string in the table is quite 
inefficient, the information may be stored in a form of 
integer, such as if the operating system is real time OS, 
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0 is stored, if the general purpose OS, 1 is stored, and if 
connmon, 2 is stored. 

[0040] Next, a process flow of the confimon interrupt 
handler 128 using the input and output device in com- 
mon for a plurality of operating systems using the fore- 
going switch table 200, will be discussed with reference 
to Rg. 13. The process discussed herein is applicable 
not only for the switch but also for other input and output 
device which require determination which operating 
systems is to be actuated by malcing judgment of the 
content of interrupt. 

[0041] The common interrupt handler 128 malces 
reference to the content of the executing OS storage 
parameter 154 after occun-ence of interrupt to check 
whether the current executed operating system is the 
general purpose OS 1 16 or the real time OS 1 17 (proc- 
ess 210). Next, reference is made to the preferential 
inten-upt table 156. If the common flag is not set, the 
operating system, to which the occurred interrupt corre- 
sponds. Is attained with reference to the preferential 
inten'upt table 156 (process 212). If the common flag is 
set, the interrupt objective operating system is deter- 
mined by making judgment of the content of interrupt by 
accessing the input and output device (process 213). 
Here, comparing the content of inten-upt and the switch 
table 200, when judgment is made that the dedicated 
switch for the real time OS is depressed, the real time 
OS 117 is stored as the inten-upt objective OS, and 
when judgment is made that the dedicated switch for the 
general purpose OS is depressed, the general purpose 
OS 116 is stored as the interrupt objective OS. When 
judgment is made that the common switch is 
depressed, reference is made to the preferential inter- 
rupt table 156, the operating system, to which the 
occurred interrupt corresponds, is attained. Here, con- 
sidering the case where the stored values in the prefer- 
ential inten-upt table 156 of Fig. 7 and the switch table 
200 of Fig. 12 are used, if IRQ#2 is assigned to switch 
interrupt, when the switch #0 is input, reference is made 
to the real time OS, when the switch #2 is input, refer- 
ence is made to the genera! purpose OS, and when the 
switch #3 is input, since the switch is for common use, 
reference is made to the preferential interrupt table 156 
again to attain the intenupt objective operating system, 
such as the real time OS. 

[0042] Next, check is performed whether the inter- 
rupt objective operating system is equal to the operating 
system in execution (process 214). If the occurred inter- 
rupt is not for the currently executed operating system, 
the operating system has to be once switched. This 
switching process is performed by requesting to the PS 
context switch module 127 (process 215). Next, check is 
perfonmed whether the inten'upt objective operating 
system is the general purpose OS 1 1 6 or the real time 
OS 11 7 (process 21 6). If the object is the general pur- 
pose OS 116, the interrupt handler 122 of the general 
purpose OS is actuated with reference to the interrupt 
address table 155 (process 21 7). If inten-upt for the real 



time OS is caused, the interrupt handler 123 of the real 
time OS is actuated with reference to the interrupt 

^ address table 155, similarly (process 218). In general, 
when the task switching has to be perfomned by the 

5 interrupt process, the interrupt handlers 122 and 123 
call the re-schedulers 1 1 8 and 1 1 9 and do not return the 
control to the common interrupt handler 128. However, 
if task switching is not caused, the process of the inter- 
rupt handler is terminated. At this time, the interrupt 

70 handlers 1 22 and 1 23 return the control to the common 
interrupt handler 128. The common interrupt handler 
128 resumes operation from the process 219. The proc- 
ess 21 9 is the process for checking whether the operat- 
ing system is switched upon occurrence of inten-upt. 

15 When the operating system is switched by the process 
215, the operating system has to be switched again to 
return to the original execution environment. Therefore, 
request is again made to the OS context switch module 
127 to execute the switching process (process 220). 

20 [0043] While discussion has been given herein- 
above for a method to make the input and output device 
in common in the system where a plurality of operating 
systems are operated on the single computer with refer- 
ence to the preferential interrupt table stored in the 

25 interrupt management table 1 29 from the common Inter- 
rupt handler provided in the inter-OS control function 
124, the method set for above cannot handle ail of the 
cases. For example, in input and output device, such as 
a graphic accelerator or a serial communication, operat- 

30 ing condition and various operation parameters are set 
from an input and output driver and holes the parame- 
ters and operating condition in the register within the 
hardware. For such input and output device, if the fore- 
going process Is simply applied, the input and output 

35 drivers and interrupt handlers in respective operating 
systems cannot recognize switching of the operating 
systems to attempt to continue process from the condi- 
tion set by the input and output driver of the preceding 
operating system. However, the parameters to be set 

40 can be nonnal values only as continued from the value 
finally set by the input and output driver of own operat- 
ing system. It should be clear that the desired operation 
cannot be done if some parameter is written in the input 
and output device between switching of the operating 

45 system. 

[0044] In order to solve this problem, the present 
invention is characterized by application of a client- 
server model for the input and output process, such as 
the input and output drivers 120 and 121 and the inter- 
so rupt handler 122 and 123 provided in each operating 
system as shown in Fig. 1 4. Namely, with one of the 
input and output process of a plurality of operating sys- 
tems, an input and output process 222 on a server side 
is executed. The server side input and output process 
55 222 behaves to manage the input and output device 226 
common for a plurality of operating systems to execute 
data input and output 225 from the input and output 
driver 121 to the input and output device 226 and to 
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operate for receiving the interrupt demand from the 
input and output device 226 by the interrupt handler 
123. Furthermore, receiving a notice of the request from 
the client side input and output process 221 to make 
judgment for the content to perform data input and out- 5 
put 225 with the input and output device 226, and 
returns the result to the client side input and output 
device 226 as a report of the result. On the other hand, 
the client side input and output device 221 transmits a 
notice 223 of request for data input and output to the 70 
input and output device 226, to the server side input and 
output device 222, for executing the input and output 
process using the returned report of the result 224. 
Accordingly, the client side input and output process 
does not directly control the hardware of the input and 75 
output device 226, and the server side input and output 
device constantly manages the input and output device. 
Therefore, no discrepancy will be caused in the operat- 
ing condition. 

[0045] It should be noted that the server side input 20 
and output process 222 is desirably set in the operating 
system having higher preferential order. In the shown 
embodiment, since it is assumed that the real time OS 
has higher preferential order than the general purpose 
OS, the server side input and output process 222 is pro- 25 
vided in the real time OS. By providing the server side 
input and output process, the operating system having 
higher preferential order can avoid occun*ence of masl<- 
ing of the process, such as inten'upt demand. Accord- 
ingly, unduly delaying of response upon occurrence of 30 
the inten-upt demand can be avoided to attain a feature 
that missing of data can be avoided. 
[0046] Hereinafter, among the modules shown In 
Fig. 14, process flow of the common interrupt handler 
128 and the interrupt handlers 122 and 123 will be dis- 35 
cussed. 
[0045] 

[0047] Operational flow of the common inten-upt 
handler 128 when the client-server model shown in Fig. 
14 is applied for Input and output process, will be dis- 40 
cussed with reference to Fig. 15. It should be noted that 
the basic system construction is similar to Rgs. 1 and 5, 
and, in the preferential interrupt table 156, for the inter- 
rupt number of the input and output device to be com- 
mon for a plurality of operating systems, the common 45 
flag 1 is stored and for the interrupt number of the input 
and output device to be used In the particular operating 
system, the common flag 0 Is stored. Furthermore, as 
shown in Fig. 14, the server side input and output proc- 
ess is provided in the real time OS 1 1 7 and the client so 
side input and output process is provided in the general 
purpose OS. 
[0046] 

[0048] The common interrupt handler 128, at first, 
takes out the content of the executing OS storage 55 
parameter 154 after occurrence of interrupt to check 
whether the cun-ently executed operating system is the 
general purpose OS 1 1 6 or the real time OS 1 1 8 (proc- 



ess 230). Next, reference is made to the preferential 
interrupt table 156 (process 231). If the common flag is 
not set, the operating system, to which the occurred 
Interrupt con-esponds, is attained with reference to the 
preferential interrupt table 156 (process 232). If the 
common flag 1 is set, the inten-upt objective operating 
system is determined by making judgment of the con- 
tent of interrupt by accessing the input and output 
device (process 233). 

[0049] Next, check is performed whether the inter- 
rupt objective operating system is equal to the operating 
system in execution (process 234). If the occun-ed inter- 
rupt is not for the currently executed operating system, 
the operating system has to be once switched. This 
switching process is performed by requesting to the PS 
context switch module 127 (process 235). Next, check is 
performed whether the interrupt objective operating 
system Is the general purpose OS 1 16 or the real time 
OS 1 17 (process 236). If the object is the general pur- 
pose OS 116, the Interrupt handler 122 of the general 
purpose OS is actuated with reference to the interrupt 
address table 155 (process 237). If interrupt for the real 
time OS is caused, the inten-upt handler 123 of the real 
time OS is actuated with reference to the interrupt 
address table 155, similarly (process 238). In general, 
when the task switching has to be perfonned by the 
interrupt process, the interrupt handlers 122 and 123 
call the re-schedulers 1 1 8 and 1 1 9 and do not return the 
control to the common interrupt handler 128. However, 
If task switching is not caused, the process of the inter- 
rupt handler is tenninated. At this time, the interrupt 
handlers 122 and 123 return the control to the common 
interrupt handler 128. The common inten-upt handler 
128 resumes operation from the process 239. The proc- 
ess 239 is the process for checking whether the operat- 
ing system Is switched upon occurrence of inten-upt. 
When the operating system is switched by the process 
235, the operating system has to be switched again to 
return to the original execution environment Therefore, 
request is again made to the OS context switch module 
127 to execute the switching process (process 240). 
[0050] Fig. 1 6 shows a process flow of the interrupt 
handler of the real time OS as a part of the server side 
Input and output device 222 called from the common 
Interrupt handler 128. 

[0051] At first, the register in use is temporarily 
stored in the interrupt stack 153 (process 250). By mak- 
ing reference to the preferential interrupt table 156, 
judgment is made whether the input and output device 
demanding interrupt is common for a plurality of operat- 
ing systems (process 251 ). If not common. It is the inter- 
rupt demand for the real time OS to execute the 
corresponding interrupt process (process 253). If com- 
mon, reference is made to the preferential interrupt 
table 156 again to make judgment to which operating 
systems, the occumng interrupt demand corresponds 
(process 252). When the flag of the real time OS side is 
set or the common flag is not set, the Interrupt process 
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for the real time OS interrupt is executed (process 253). 
When the flag of the general purpose OS side is set, the 
interrupt process for the general purpose OS interrupt is 
executed (process 254). Here, the Interrupt process 254 
in the general purpose OS inten*upt notifies occurrence 5 
of inten-upt to the client side interrupt handler 122 to 
generate software interrupt to the general purpose OS 
116. Furthermore, if necessary, information obtained 
through the software Inten-upt process Is written in the 
common memory 125. It should be noted that the gen- to 
erated software interrupt has to be provided lower pref- 
erential order than the Interrupt process executed 
currently. In execution of the interrupt process for the 
general purpose OS interrupt, since judgment for task 
switching is not required for no influence to the real time 75 
OS at all, the process of the interrupt handler 123 Is ter- 
minated. Therefore, the register value temporarily 
stored in the inten'upt staclc 153 is restored (process 
259), and the control is returned to the common inter- 
rupt handler (process 260). It should be noted that omit- 20 
ting of the process 255 is for speeding up of the 
process, and no problem wilt be arisen even in opera- 
tion to execute the process 255. 
[0052] On the other hand, after execution of the 
inten-upt process corresponding to the real time OS 25 
Interrupt (process 253), judgment is made whether task 
switching is necessary or not (process 255). If task 
switching is necessary, process of the Interrupt handler 
123 is terminated. Therefore, the register value tempo- 
rarily stored on the interrupt stack 1 61 is restored (proc- 30 
ess 259), and the control Is returned to the common 
inten-upt handler (process 260). When judgment is 
made that task switching is necessary, the register 
value temporarily stored on the interrupt stack 151 is 
copied in the task management table (process 256), 35 
and the temporarily stored register on the inten-upt stack 
is abandoned (process 257). Thereafter, the re-sched- 
uler 119 is actuated (process 258). It should be noted 
that if the processor 100 is provided with a function to 
increase and decrease the value of the Interrupt stack 40 
pointer 158 in conjunction with making reference to data 
on the memory, the processes 256 and 257 may be exe- 
cuted in a lump. 

[0053] On the other hand, the interrupt handler 1 22 
of the general purpose OS actuated by the software 45 
inten-upt generated by the interrupt handler 123, exe- 
cutes the process of the same content as the operation 
flow with reference to Fig. 10 in most part. It should be 
noted that what is partially differentiated is execution of 
the interrupt process con-esponding to interrupt shown so 
in the process 181. Information obtained therein is writ- 
ten in the common memory 125. Accordingly, the proc- 
ess 181 in the interrupt handler 122 read out the 
information stored in the common memory 125 to oper- 
ate to execution of the process conresponding to the 55 
interrupt to realize the interrupt process without directly 
accessing the input and output device. 
[0054] On the other hand, even when the client- 



server model discussed in connection with Fig. 14 is 
applied and the input and output device Is In common 
for a plurality of operating systems, similarly to the dis- 
cussion given for Figs. 11 to 13, it can occur a case 
where judgment cannot be made with which operating 
system the interrupt process is to be executed unless 
content of inten-upt is checked. The process flow of the 
interrupt handler 1 23 provided in the real time OS 1 1 7 in 
this case will be discussed with reference to Fig. 1 7. It 
should be noted that the table for making judgment of 
the content of interrupt is established under the premise 
where the switch table 200 is used in similar manner as 
that discussed above, the process discussed herein is 
applicable not only for the switch but also for other input 
and output device. 

[0055] At first, the register in use is temporarily 
stored in the interrupt stack 1 53 (process 270). By mak- 
ing reference to the preferential interupt table 156, 
judgment is made whether the input and output device 
demanding inten-upt is common for a plurality of operat- 
ing systems (process 271 ). If not common, it is the inter- 
rupt demand for the real time OS to execute the 
corresponding interrupt process (process 274). If com- 
mon flag is set, the inten-upt objective operating system 
is judged by making judgment of the content of interrupt 
(process 272). Comparing the content of interrupt and 
the switch table 200, when judgment is made that the 
dedicated switch for the real time OS is depressed, the 
real time OS 1 17 is stored as the interrupt objective OS, 
and when judgment is made that the dedicated switch 
for the general purpose OS is depressed, the general 
purpose OS 1 1 6 is stored as the inten-upt objective OS. 
On the other hand, when judgment is made that the 
common switch is depressed, reference is made to the 
preferential Intenupt table 156, the operating system, 
for which the flag is set, is stored as the interrupt objec- 
tive OS. Here, considering the case where the stored 
values in the preferential interrupt table 156 of Fig. 7 
and the switch table 200 of Fig. 12 are used, and IRQ#2 
is assigned to switch inten-upt, when the switch #0 Is 
input, reference is made to the real time OS, when the 
switch #2 is input, reference is made to the general pur- 
pose OS, and when the switch #3 is input, since the 
switch is for common use, reference is made to the pref- 
erential interrupt table 156 again to attain the inten-upt 
objective operating system, such as the real time OS. 
[0056] Next, with reference to the inten-upt objective 
OS (process 273), if it is the real time OS 11 7, the inter- 
rupt process for the real time OS interrupt is executed 
(process 274). If it is the general purpose OS 116, the 
interrupt process 274 for the general purpose OS inter- 
rupt is executed (process 275). Here, the interrupt proc- 
ess 275 for the general purpose OS interrupt generates 
software interrupt for the general purpose OS 116 in 
order to notify the occun-ence of inten-upt to the client 
side interrupt handler 122. Furthermore, if necessary, 
information obtained through the software inten-upt is 
written in the common memory 125. It should be appre- 
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ciated that the generated software interrupt has to be 
provided lower preferential order than the Interrupt proc- 
ess In execution. 

[0057] In interrupt process execution corresponding 
to the general purpose OS inten^upt, judgnnent of task 5 
switching is not necessary for not influencing to the real 
time OS at all. Accordingly, the process of the inten-upt 
handler is terminated. Then, the register value tempo- 
rarily stored in on the interrupt stacl< 153 is restored 
(process 280), and the control is returned to the com- io 
mon interrupt handler (process 281). It should be appre- 
ciated that omitting of the process 276 Is for speeding 
up of the process, and no problem will be arisen even in 
operation to execute the process 276. 
[0058] On the other hand, after execution of the is 
interrupt process corresponding to the real time OS 
inten-upt, judgment is made whether task switching is 
necessary or not (process 276). If task switching is nec- 
essary, process of the inten-upt handier 123 is termi- 
nated. Therefore, the register value temporarily stored zo 
on the inten-upt stack 153 is restored (process 280), and 
the control is returned to the common interrupt handler 
(process 281). When judgment is made that task 
switching is necessary, the register value temporarily 
stored on the inten-upt stack 151 is copied In the task 25 
management table (process 277), and the temporarily 
stored register on the inten-upt stack is abandoned 
(process 278). Thereafter, the re-scheduler 1 1 9 is actu- 
ated (process 279). 

[0059] As set forth above, the method to apply the so 
client-server model as the method for using the same 
input and output device in common for a plurality of 
operating systems, has been discussed. Here, while 
discussion has been given for a method to notify the 
occun^nce of interrupt from the server side operating 35 
system to other operating system by software interrupt, 
if some communication means is provided, it becomes 
possible to notify occurrence of Inten-upt from the server 
side input and output process 222 to the client side input 
and output process 221 . It can be replaced for the soft- 40 
ware interrupt set forth above. In the shown embodi- 
ment, in order to establish communication between two 
operating systems, the inter-OS communication func- 
tion 126 as shown in Fig. 1 is provided. Therefore, a 
method for making the Input and output device common as 
for a plurality of operating systems will be discussed 
with reference to Fig. 1 8. 

[0060] Most of Components in Fig. 1 8 are the same 
as components discussed in connection with Figs. 1 
and 5, but are differentiated in a virtual input and output so 
driver 290 and a virtual Interrupt handler 291 are pro- 
vided in place of the input and output driver 120 and the 
inten-upt handler 122 provided in the general purpose 
OS 1 1 6. The virtual input and output driver 290 provides 
an Interface for accessing the input and output device ss 
from an application task but does not directly read and 
write the input and output device and directly control the 
input and output device. Here, using the message com- 



munication provided by the inter-OS communication 
function 126, reading and writing and control are 
requested to the input and output driver 121. Also, the 
result is also received from the input and output driver 
121 using the message communication. The virtual 
Interrupt handler 291 is actuated by the message trans- 
mitted from the inten-upt handler 123 to execute the 
interrupt process. 

[0061 ] Next, flow of the process upon occurrence of 
the interrupt demand for the input and output device 
common for both of the operating systems will be dis- 
cussed with reference to Fig. 18. For convenience of 
illustration, In the preferential interrupt table of the Inter- 
rupt number generated by the input and output device 
handled herein, the common flag 1 is set, and also, the 
flag is set on the side of the general purpose OS. 
[0062] The interrupt demand generated by the input 
and output device is once trapped in the common inter- 
rupt handler 128. The process is executed according to 
the flow of Rg. 15. Here, since It is assumed that it is 
interrupt from the input and output device in common for 
both of the operating systems, the interrupt handler 123 
provided in the real time OS is actuated. The interrupt 
handler 123 executes the process according to the flow 
discussed in connection with Fig. 1 6. Here, since it is 
assumed that common flag is set in the preferential 
interrupt table 156 and flag is set in the general purpose 
OS, the interrupt process 254 con-esponding to the gen- 
eral purpose OS inten-upt is executed. Here, the inter- 
rupt process 254 for the general purpose OS Interrupt 
transmit the message to the virtual interrupt handler 291 
on the client side using the inter-OS communication 
function in order to notify occurrence of inten-upt to the 
virtual interrupt handler 281 on the client side. It should 
be noted that infomriatlon obtained through the Interrupt 
process may be transmitted with attaching to the mes- 
sage, and may transmit information by writing In the 
common memory 1 25 and making reference to from the 
virtual inten-upt handler 291 . Furthermore, when a mes- 
sage queue for receiving the message is not provided in 
the virtual interrupt handler 291, the message is trans- 
mitted once to the server task 1 12 provided as the appli- 
cation task and the virtual interrupt handler 291 is called 
from the server task 1 12 for actuating the virtual inter- 
rupt handler 291 . The virtual Interrupt handler 291 exe- 
cutes the inten-upt process by making reference to the 
result of process of the inten-upt process attached to the 
message or the common memory 125 . 
[0063] Furthermore, the flow of process for execut- 
ing the input and output process requested from the 
task provided in the general purpose OS will be dis- 
cussed with reference to Fig. 19. The virtual input and 
output driver 290 in the general purpose OS is only 
Interface for accessing the input and output device from 
the office work IS, and requested input and output proc- 
ess is transferred to the input and output driver 121 
using the inter-OS communication function 126. It 
should be noted that the infomnation obtained by the vir- 
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tual input and output driver 290 may be transmitted with 
attaching to the message, and also may be written in 
the common memory 125 and made reference to from 
the input and output driver 121 for transferring informa- 
tion. Furthermore, when the message queue for receiv- 5 
ing the message is not provided in the input and output 
driver 121, the message Is transmitted once to the 
server task 113 provided In the application task to actu- 
ate the input and output driver 121 by calling the input 
and output driver 121 from the server tasl< 113. The to 
input and output driver 121 executed the input and out- 
put process by making reference to the content of 
request attached to the message or the common mem- 
ory 125. 

[0064] Next, flow of re-writing of the preferential is 
intenupt table provided In the Inter-OS control function 
124 will be discussed with reference to Fig. 20. The 
preferential interrupt table 156 is re-written by the man- 
agement task 1 1 5 managing the user demand or so 
forth. However, It is possible to cause mismatching 20 
when the inten-upt process makes reference to the pref- 
erential interrupt table during re-writing of the preferen- 
tial interrupt table 156. Therefore, initially, all interrupt 
demand is masked so as not to cause any interrupt 
(process 301). It should be appreciated that it is also 25 
possible to mask only Interrupt demand for the interrupt 
number for which re-writing is to be effected. After set- 
ting the interrupt mask, the content of the preferential 
inten-upt table 156 is updated (process 302) and then 
the set inteniipt mask is released (process 303) to per- 30 
mit re-writing of the preferential interrupt table 1 56. 
[0065] As set forth above, the method to make the 
input and output device common for a plurality operating 
systems has been discussed, an example of application 
of the present invention for a graphic display of a built-in 35 
equipment having a user interface, such as a vehicle 
mounted navigation system, as practical application, 
will be discussed with reference to Fig. 21. It should be 
noted that the operating system operated on the graphic 
display systems are the general purpose OS 116 and 40 
the real time OS 117 similarly to Fig. 1, and a 
task/thread operating on the real time OS is assumed to 
have higher preferential order than a task/thread operat- 
ing on the general purpose OS. 

[0066] The graphic display device has graphic driv- 45 
ers 310 and 312 parsing command for drawing and dis- 
playing and controlling a graphic hardware 314, graphic 
inten-upt handlers 311 and 313 to be actuated by the 
inten-upt demand generated by the graphics hardware, 
and the graphic hardware 314 displaying an image data so 
developed to the pixels. The graphic hardware 314 has 
a frame memory 316 storing luminance value of each 
pixel and display control 315 taking out the luminance 
value of each pixel from the frame memory 31 6 per ver- 
tical synchronization frequency to output to the display 55 
104. Here, in the frame memory, conflict of resource is 
avoided by making the a drawing region 31 7 for general 
purpose OS storing image generated by the graphic 



driver 310 of the general purpose OS and a drawing 
region 31 8 for the real time OS storing image generated 
by a graphic f¥driver 312 of the real time OS independ- 
ent or separated. By this, upon switching of the operat- 
ing system, respective drawn image are stored. Even 
when the operating system is switched again, the proc- 
ess can be continued from the condition before switch- 
ing. On the other hand, it is assumed that the graphic 
driver 312 and the graphic interrupt handler 313 pro- 
vided in the real time OS operate as server, and the 
graphic driver 31 0 and the graphic interrupt handler 31 1 
provided in the general purpose OS operate as client. 
[0067] Operational flow in drawing and display 
demand from the application task incorporated in the 
real time OS will be discussed at first. The application 
task calls the drawing command provided in the graphic 
driver 312 to execute the drawing process. The drawing 
command is consisted of command for drawing line or 
polygon and commands designating attribute, such as 
line width, blotting pattern. The graphic driver 312 
parses the drawing command to develop the pixels in 
the drawing region 318 for the real time OS. If the 
graphic hardware 314 includes an acceleration function 
executing developing the pixels by hardware, such func- 
tion may be used. When drawing is completed, then, the 
display command provided in the graphic driver 312 is 
executed. The display command is consisted of a dis- 
play start address in the frame memory 31 6 and a com- 
mand designating a display size to display the image 
designated by controlling the register In the display con- 
trol 315. When the displaying of the designated image is 
started, the display control generates an interrupt 
demand. The interrupt demand is once trapped in the 
common interrupt handier 128, and instantly judged as 
the interrupt demand from the common device to call 
the graphic interrupt handler 313. By this, the graphic 
interrupt handler 313 detects that the image is dis- 
played. 

[0068] Next, operational flow in the drawing and dis- 
playing demand from the application task incorporated 
in the general purpose OS 116 will be discussed. The 
application task calls drawing command provided in the 
graphic driver 310 to develop the pixels in the drawing 
region 317 for the genera! purpose OS. When drawing 
Is completed, then, the display command provided in 
the graphic driver 310 is executed. The display com- 
mand transfers message designating the display start 
address and the display size In the frame memory 316 
to the graphic driver 312 using the inter-OS communica- 
tion function 126. The graphic driver 312 receiving the 
demand displays the designated image by controlling 
the register in the display control 31 5. It should be noted 
that the graphic driver 312 makes judgment display 
demand from which operating systems has higher pref- 
erence, to constantly display the frame memory to be 
preferentially displayed. When displaying of the desig- 
nated image is started, the display control 315 gener- 
ates the interrupt demand. The inten-upt demand is 
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once trapped by the common interrupt handler 128, and 
instantly judged as interrupt demand from the common 
device to actuate the graphic interrupt handler 313. The 
graphic inten^upt handler 313 transfers the received 
inten-upt demand to the graphic interrupt handler 31 1 5 
using the inter-OS communication function 126. By this, 
the graphic interrupt handler 31 1 detects that the image 
is displayed. 

[0069] The particular embodiment of the graphic 
display system, to which the present invention has been 10 
discussed hereinabove, various peripheral devices, 
such as serial/network communication, CD-ROM/DVD- 
ROM storage device, can be made common for a plural- 
ity of operating systems by application of the present 
invention. 75 
[0070] According to the present invention, in the 
computer system operating a plurality of operating sys- 
tems with the single processor, the same input and out- 
put device can be used in common from the application 
tasks executed by respective operating systems to per- 20 
mit reduction of total number of the input and output 
devices. Furthennore, according to the present inven- 
tion, the input and output device common for a plurality 
of operating systems and the input and output driver for 
data input and output, and the interrupt handier are 2s 
loaded in one operating system, and by requesting input 
and output process to the input and output driver and 
the interrupt handler from the other operating system, 
the input and output process can be continued without 
resetting the Input and output device to improve opera- 30 
bility. 

[0071] Although the present Invention has been 
illustrated and described with respect to exemplary 
embodiment thereof, It should be understood by those 
skilled In the art that the foregoing and various other 35 
changes, omission and additions may be made therein 
and thereto, without departing from the spirit and scope 
of the present invention. Therefore, the present inven- 
tion should not be understood as limited to the specific 
embodiment set out above but to include all possible 40 
embodiments which can be embodied within a scope 
encompassed and equivalent thereof with respect to the 
feature set out in the appended claims. 



wherein said preferential interrupt table 
stores whether the inten-upt is from a peripheral 
device common in a plurality of operating systems 
or not in addition to the operating systems to be 
actuated per intenoipt factor. 

3. A computer system as set forth in claim 2, 

the OS switching means makes reference to 
the preferential interrupt table on the basis of 
inten-upt factor, makes judgment whether the 
Inten-upt demand is for inten-upt common for a 
plurality of operating systems, determines 
operating system to be objective for interrupt by 
parsing the content of the peripheral device 
generating interrupt as judged to be common 
inten-upt, for switching the operating system, 
and in conjunction therewith for calling interrupt 
processing means provided in said operating 
system. 

4. A computer system comprising: 

a plurality of operating systems; 

OS switching means for switching a plurality of 

operating systems; 

peripheral device to be common for a plurality 
of operating systems; 

data inputting and outputting server for Input- 
ting and outputting data with the peripheral 
device to be used in common, providing In one 
of the operating systems; and 
data inputting and outputting client for inputting 
and outputting data with the operating system 
other than said one operating system, request- 
ing inputting and outputting data to said data 
inputting and outputting server and executing 
inputting and outputting of data by receiving a 
result of data inputting and outputting with the 
peripheral server in the data inputting and out- 
putting server. 

5. A computer system as set forth in claim 4, 



Claims 45 

1 . A computer system comprising: 

a plurality of operating systems; and 
OS switching means for switching a plurality of so 
operating systems, said OS switching means 
making reference to a preferential interrupt 
table on the basis of an interrupt factor for 
switching to corresponding operating system 
and calls interrupt processing means incorpo- 55 
rated in said operating system. 

2, A computer system as set forth in claim 1 , 



which further comprises a preferential interrupt 
table storing operating system to be actuated 
per interrupt factor and preferential interrupt 
table re-writing means for re-writing the prefer- 
ential interrupt table. 

said OS switching means makes reference to 
the preferential interrupt table per inten-upt fac- 
tor, makes judgment whether the Interrupt 
demand is for interrupt to be common for a plu- 
rality of operating systems, and calls interrupt 
processing means included in said data Input- 
ting and outputting server If judged as common 
interrupt. 
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6. A computer system as set forth in claim 4, wherein 

said data inputting and outputting server is pro- 
vided in a region managed by the operating 
system having the highest preferential order. s 

7. A computer system as set forth in claim 4, 

which comprises inter-OS communication 
means for mutual communication between a io 
plurality of operating systems, 
said data inputting and outputting server and 
said data Inputting client means are communi- 
cated. 

15 

8. A computer system as set forth in claim 5, wherein 

said data inputting and outputting server is pro- 
vided in a region managed by the operating 
system having the highest preferential order. 20 

9. A computer system as set forth in claim 5, 

which comprises inter-OS communication 
means for mutual communication between a ss 
plurality of operating systems, 
said data inputting and outputting server and 
said data inputting client means are communi- 
cated. 
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